Skip to main content
Expert Talk
Amakomaya — Aamako Maya Apps Pvt. Ltd.

Facility Registry

The facility registry is the authoritative list of places where health services are delivered, each with a permanent identifier. It is the least glamorous component in a health information exchange and the one to build first.

Almost everything depends on it. Aggregate reporting is by facility. Supply chain distribution is to facilities. Referrals are between facilities. Human resource allocation is per facility. Coverage denominators are computed from catchment populations of facilities. When each system holds its own facility list, none of these can be reconciled — and this is the normal state of affairs in most countries.

Why it is first​

  • Small. Thousands of records, not millions.
  • Not personal data. No consent or privacy regime blocks it, so it can be published openly.
  • Politically tractable. Nobody has strong objections to a shared list of clinics.
  • Immediately useful. It improves reporting quality on its own, before any other exchange component exists.
  • Blocking. Client registry, LMIS, HMIS and HIE all need it.

A country with no digital health infrastructure at all can build a facility registry in months and see benefit. That is rarely true of anything else in this architecture.

What it holds​

AttributeNotes
IdentifierPermanent, namespaced, never reused — even after closure
NameOfficial name, plus known aliases and local-language forms
TypeHospital, health post, clinic, laboratory, pharmacy, warehouse — from a controlled list
OwnershipPublic, private for-profit, private not-for-profit, faith-based, military
Administrative hierarchyWard → municipality → district → province → country, or the local equivalent
GeographyLatitude and longitude, with a stated coordinate precision and source
Operational statusOperational, temporarily closed, permanently closed, planned
Services offeredWhich of a controlled service list; ideally with availability
CapacityBeds, delivery rooms, cold chain capacity
ContactPhone, in-charge, email
Effective datesOpened, closed, renamed, reclassified
Cross-referencesIdentifiers used by other systems, historically

Not held: monthly reporting data, staffing rosters, stock levels. Those live in the HMIS, the health worker registry and the LMIS respectively, each linked by facility identifier.

Hierarchy is harder than it looks​

Two hierarchies usually coexist and do not align:

   Administrative                    Service delivery
   ──────────────                    ────────────────
   Province                          Referral hospital
     └ District                        └ District hospital
        └ Municipality                    └ Health post
           └ Ward                            └ Community unit / outreach
              └ Facility

A facility sits in an administrative unit and in a referral network, and the two are not nested the same way. A private hospital may take referrals across district boundaries; an outreach site may belong to a facility rather than to a place.

Model both, explicitly. Trying to force one hierarchy produces the familiar symptom where a facility's district changes for reporting purposes and three years of trend data breaks.

Also: administrative boundaries change. Redistricting, municipal amalgamation and new provinces are normal. The registry must record which hierarchy was in force when, or historical reporting becomes uninterpretable.

Versioning is the core requirement​

Facilities open, close, merge, split, get renamed and get reclassified. If the registry only holds current state, historical data becomes unattributable.

Rules that make this work:

  1. Identifiers are never reused. A closed facility's identifier is retired permanently.
  2. Every change is dated. Name, type, hierarchy and status all carry effective periods.
  3. Closed facilities still resolve. A query for a 2019 record must return the facility as it was in 2019.
  4. Merges and splits are modelled explicitly, with predecessor and successor links — not by editing one record and deleting another.
  5. There is a change feed, so downstream systems can synchronise without re-downloading everything.

Geography​

Coordinates matter for catchment analysis, accessibility modelling, outbreak mapping and supply routing. See GIS.

Practical concerns:

  • Record the source and precision of each coordinate — GPS at the door, digitised from a map, or the centroid of the ward. These differ by kilometres and are routinely conflated.
  • Validate against boundaries. A facility whose coordinates fall in the neighbouring district is either mis-located or mis-assigned; both need investigation.
  • Coordinates are sensitive in some contexts — facilities serving stigmatised populations, and facilities in conflict zones. "Not personal data" does not always mean "publish everything".

Interfaces​

The registry needs three, and most implementations build only the first:

  1. Query API — search by name, code, type, location, hierarchy. FHIR Location and Organization, or a national API.
  2. Change feed — what changed since a timestamp, so downstream systems stay current cheaply.
  3. Bulk snapshot download — a file, versioned and dated, for systems that cannot call an API, including offline CHW applications. This is the interface that makes the registry usable at the edge.

The DHIS2 question​

In many countries the de facto facility list is the DHIS2 organisation unit hierarchy, because that is where reporting happens and therefore where the list is maintained.

This is a legitimate starting point and a poor permanent arrangement:

  • The DHIS2 hierarchy is shaped by reporting needs, so it contains reporting units that are not facilities and omits facilities that do not report
  • Private facilities are often absent
  • Historical versioning of org units is limited
  • Other systems must then integrate with DHIS2 to obtain facility identity, coupling the whole ecosystem to the HMIS

The pragmatic path: seed a facility registry from the DHIS2 hierarchy, establish a separate stewardship process, and then have DHIS2 consume the registry rather than define it. Record the decision and the migration plan in an ADR.

Stewardship​

The registry decays without an owner. Minimum viable process:

  • A named unit responsible for it, with authority to approve changes
  • A submission route for facilities and districts to request additions and corrections
  • Verification before publication — a new facility needs evidence, or the registry fills with duplicates and aspirational entries
  • A published release cycle, so downstream systems know when to expect changes
  • Quality metrics, published: coordinate completeness, duplicate rate, records not updated in over a year, facilities reporting to HMIS but absent from the registry

Standards and tooling​

  • FHIR — Location (a physical place), Organization (the entity that runs it), HealthcareService (what is offered). Model these separately; a single "facility" record conflates place, entity and service, and the conflation surfaces later when a hospital's ownership changes.
  • GOFR — Global Open Facility Registry work in the OpenHIE community, aimed at reconciling facility lists between organisations
  • DHIS2 metadata API — where the list currently lives in many countries
  • Master Facility List guidance — WHO has published guidance on establishing a national master facility list; see the reference below

References​

Last updated on